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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 



Introduction 

0.1 Overview 

The TIPHON system is a multi-component system. Its architecture consists of several planes, including the 

IP Telephony plane, as defined in TS 101 314 [16]. ITU-T Recommendation H.323 [8] defines three types of entities: 

H.323 [8] Terminals, Gateways, and Gatekeepers. 

The procedures of ITU-T Recommendations H.323 [8], H.225.0 [5] and H.245 [7] shall apply with the limitations or 
extensions described in the present document. The procedures of ITU-T Recommendation H.235 [6] shall apply 
unchanged. A TIPHON compliant system shall support the Gatekeeper Routed Call (GRC) model. The Direct Routed 
Call (DRC) model is optional. 

In accordance with ITU-T Recommendation H.323 [8], the protocol defined in ITU-T Recommendation H.225.0 [5] 
and the protocol defined in ITU-T Recommendation H.245 [7] shall be used for call control signalling and logical 
channel controlling within the packet based data network. The use of ITU-T Recommendations H.225.0 [5] and 
H.245 [7] is specified in more detail in the following clauses. 

NOTE: ITU-T Recommendation H.225.0 [5] defines two protocols: Registration, Admission, and Status (RAS) 
protocol and an ITU-T Recommendation Q.931 [13] -like call control protocol. 

The TIPHON profile for ITU-T Recommendation H.225.0 [5] is given in annex A. 

The RAS protocol of ITU-T Recommendation H.225.0 [5] shall apply unchanged. 

The ASN.l definitions given in annex H of ITU-T Recommendation H.225.0 [5] shall be used. 

The precise translation of ITU-T Recommendation H.323 [8] messages to the SCN and vice versa shall depend on the 
nature of the SCN (an ISDN, a PSTN, etc.) and the level of connectivity to be supported. This translation shall provide 
support, as necessary, of: 

the semantics of the protocol specified in ITU-T Recommendations Q.761 [9], Q.762 [10], Q.763 [11] and 
Q.764 [12] with variations in implementation appropriate to the region in which the SCN operates; or 

the semantics of the protocol specified in ITU-T Recommendation Q.931 [13] with variations in implementation 
appropriate to the region in which the SCN operates; or 

the semantics of the protocol specified in ISO/IEC 1 1572 [3]. 
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For the optional support of Simple Endpoint Types defined in ITU-T Recommendation H.323 Annex F [8], refer to 
clause 5.9 "Support of SET devices". 



0.2 Security principles 



If security services are required, TIPHON compliant systems shall support the security profiles defined in [1]. Security 
services are not required always to be activated. 
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Scope 



The present document describes interactions between ITU-T Recommendation H.323 [8] Terminals, Gatekeepers, 
Gateways, and Switched-Circuit Networks (SCN) for support of TIPHON scenarios 1, 2, 3, and 4, as defined in 
TR 101 300 [15]. 

The present document defines the interactions that are necessary for: 

• the delivery of telephone calls which originate in an Internet Protocol (IP) network and are delivered to 
Switched Circuit Networks (SCN); 

• the delivery of telephone calls which originate in SCNs and are delivered in an IP network; 

• the delivery of telephone calls which originate in SCNs, routed through a IP network and finally delivered to an 
SCN; and 

• the delivery of telephone calls which originate and terminate in IP networks. Such calls may be routed using an 
SCN. 

The present document specifies a profile to be applied to the ITU-T Recommendation H.323 [8] for the purposes of 
TIPHON compliant systems. 

Call trace protocols, e.g. for use in tracing malicious calls, and interactions with Network Address Translation (NAT) 
and firewall devices are outside the scope of the present document. 

The present document is applicable to equipment performing the roles of H.323 [8] Terminals, gatekeepers or gateways. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access token: octet string which may be present in Registration, Admission, and Status (RAS) messages and the Setup 
message. It is used to specify the identity, authorization, or other security characteristics of a network element or a user 

Call: see "telephone call" 

E.164 [4] number: number conforming to the numbering plan and structure specified in 
ITU-T Recommendation E.164 [4] 

Endpoint: H.323 [8] Terminal or Gateway. An endpoint can call and be called. It generates and terminates information 

streams 

Gatekeeper: H.323 [8] entity on the network that provides address translation and controls access to the network for 
H.323 [8] Terminals and Gateways. The Gatekeeper may also provide other services to the H.323 [8] Terminals and 
Gateways such as bandwidth management and locating Gateways 

Gateway: endpoint on the network which provides for real-time, two-way communications between H.323 [8] 
Terminals on the packet based network and other Terminals on a switched circuit network 

H.323 [8] Terminal: entity which provides audio and optionally video and data communications capability in 
point-to-point or multipoint conferences in packet-based networks. In the scope of the present document, only the audio 
capabilities are considered 

Switched Circuit Network (SCN): telecommunications network, e.g. Public Switched Telephone Network (PSTN), 
Integrated Services Digital Network (ISDN), and General System for Mobile communications (GSM), that uses circuit- 
switched technologies for the support of voice calls. The SCN may be a public network or a private network 

Telephone call: two-way speech communication between two users by means of Terminals via network infrastructure 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply in addition to the abbreviations defined in 
TR 101 300 [15] and TS 101 314 [16]: 

ACF AdmissionConfirm (RAS message) 

ARQ AdmissionRequest (RAS message) 

ASN. 1 Abstract Syntax Notation number 1 

C Conditional 

CLI Calling Line Identification 

CLIP Calling Line Identification Presentation 

DSS1 Digital Subscriber Signalling System No. One 

DTMF Dual-Tone Multi-Frequency 

DRC Direct Routed Call 

GK Gatekeeper 

GRC Gatekeeper Routed Call 

IP Internet Protocol 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part [11] 

M Mandatory 

NAT Network Address Translation 

O Optional 

PISN Private Integrated Services Network 

PSTN Public Switched Telephone Network 

RAS Registration, Admission, and Status 

RCF Registration Confirm (RAS message) 

RRQ Registration Request (RAS message) 

SCN Switched-Circuit Network 

SET Simple Endpoint Type 



Void 



5 Registration 

5.1 Registration basics 

Both H.323 [8] Terminals and Gateways shall register with Gatekeepers. Registration shall be in accordance with 
ITU-T Recommendation H.323 [8] procedures. TIPHON compliant endpoints shall use Automatic Gatekeeper 
Discovery. 

TIPHON compliant Gatekeepers shall issue the PreGrantedARQ indication in the Registration Confirm (RCF) 
message (RAS message) on successful registration of the Gateways and Terminals. 

Two types of registration shall be supported: 

authenticated registration with the Gatekeeper; and 

anonymous registration with the Gatekeeper. 

5.2 Authenticated Registration 

Authenticated Registrations shall be in accordance with the security profiles in TS 101 323 [1]. 
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5.3 Anonymous Registration 

In this case the Registration Request (RRQ) message (RAS message) shall not contain an access token. 

5.4 Registration Keep Alive 

Endpoints and Gatekeepers shall support the keep alived procedure as specified in clauses 7.2.2 and 8.4.2 of 
ITU-T Recommendation H.323 [8]. If the registration ceases to be valid (e.g. the connection between the 
H.323 [8] Terminal and its Gatekeeper goes down for some reason), the Gatekeeper shall remove the registration and 
release all ongoing calls associated with that terminal. A new registration may be established using the procedures of 
clause 5.2.2 of ITU-T Recommendation H.323 [8]. 

NOTE: Initial RRQ messages requesting a timeToLive for registration purposes and RRQ messages containing 
the keepAlive bit for restarting the receiver's timer are different matters. Endpoints shall not reuse the 
initial RRQ message as replacement for a "keepAlive message" as this may confuse the Gatekeeper. 

5.5 Call setup prerequisites 

Calls to or from users in the Internet Protocol (IP) network shall be setup only after successful registration according to 
the clauses above. 



6 Calls from an H.323 Terminal to a terminal in an SCN 

6.1 Overview 

A call from an H.323 [8] Terminal to a terminal in an SCN can be separated in three phases: call setup, active phase and 
call release. Figure 1 shows the information flows related to call establishment. 
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(note 2) 




(note 3) 



NOTE 1 : As soon as the Gatekeeper has received sufficient digits to route the call, it shall send Setup to the 

Gateway. 
NOTE 2: Information messages may be sent as a result of a user providing more information. 
NOTE 3: If the SCN has received sufficient digits to complete number analysis, Call Proceeding shall be sent 

instead of Setup Ack in response to Setup and the Information message(s) will be discarded. 

Figure 1 : Example of Scenario 1 call setup diagram using overlap sending 

6.2 Call setup 
6.2.1 Basic call setup 

Calls shall be setup using the procedures defined in ITU-T Recommendation H.323 [8] with the following 
changes/clarifications: 

- Within the context of the present document, call setup shall use only one user channel towards the SCN. Calls 
requiring a number of user channels shall not be supported. 

The Gatekeeper and its Gateway shall support both the en-bloc and the overlap sending procedure. 

In the case where two endpoints are registered to different Gatekeepers and the Gatekeeper -routed call model is 
used, TIPHON-compliant systems should use "called endpoint signalling." according to ITU-T Recommendation 
H.323 [8] clause 8.1.6. 
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NOTE 1 : "Called endpoint signalling" is of benefit with regard to the use of NAT and firewall devices. However, 
its use is an administrative decision. 

Within IP networks, if an element or a message not allowed to be used within the context of the present document is 
received, the receiver shall pass on, but otherwise ignore, the message or the element i.e. the receiver shall act as if the 
message or the element was not received. 

Within IP networks, if an element is received with a value, not allowed within the context of the present document, the 
receiver shall, if the element is optional, pass on, but otherwise ignore, the element (act as if the element is not received) 
or if the element is mandatory act as if the default value was received. 

At a Gateway, the requirements of the SCN protocol shall modify the error handling procedures described above. A 
Gateway shall not pass on to the SCN any messages or information elements, or the contents of information elements, 
that would cause a protocol error in the SCN. Similarly, a Gateway shall not pass on to the IP network any messages or 
information elements, or the contents of those information elements, that would cause a protocol error in the IP 
network. Such messages, information elements, or the contents of information elements should be mapped to suitable 
alternative if such exist, be discarded if not mandatory to support, or be rejected by the Gateway. 

NOTE 2: The security policy of an operator's network or the security policy implemented in a network element may 
override the error handling as described above. 

6.2.2 En-bloc Procedure 

The En-bloc procedure may be explicitly indicated in the signalling from the H.323 [8] terminal. En-bloc procedure 
shall also be used whenever the Called Party Number in the Setup message can be regarded as complete by the 
Gatekeeper. 

NOTE: A Called party number can be regarded to be complete under the following conditions: 

if the Gatekeeper has the full knowledge about the Called party's numbering plan and can identify the 
number to be complete; 

if the SETUP message contains the Sending complete information element; 

if the canOverlapSend parameter is absent or set to FALSE; 

if the Called party number contains the '#' character as the last digit; or 

if an entity other than a Gateway determines that a CALL PROCEEDING message is returned to the 
H.323 [8] Terminal, the "Sending complete" information element shall be inserted, if not already there, in 
the SETUP message or INFORMATION message being sent towards the next network element 
(e.g. next Gatekeeper or a Gateway). 

6.2.3 Overlap sending 

On receipt of a SETUP message with a Called party number which the Gatekeeper cannot determine to be complete, the 
Gatekeeper starts timer T302 (the value of timer T302 is specified in ITU-T Recommendation Q.931 [13]) and sends a 
SETUP ACKNOWLEDGE message back. 

The Gatekeeper shall restart timer T302 on the receipt of every INFORMATION message not containing a sending 
complete indication and containing the called party information element with at least one valid character. 

NOTE: See the previous clause for the conditions when the Called party number can be regarded to be complete. 

6.2.4 Establishment of media channels 
6.2.4.1 Fast Connect procedure 

TIPHON-compliant systems shall use the Fast Connect procedure of ITU-T Recommendation H.323 [8] clause 8.1.7. 

NOTE: This includes the capability to negotiate media channels by encapsulating ITU-T Recommendation 
H.245 [7] OLC message inside the SETUP message and the fallback to ITU-T Recommendation 
H.245 [7] signalling at any time of the call if necessary. 
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6.2.4.2 Encapsulation of H.245 messages within H. 225.0 messages 

TIPHON-compliant systems shall support encapsulation of ITU-T Recommendation H.245 [7] messages within 
ITU-T Recommendation H.225.0 [5] messages according to ITU-T Recommendation H.323 [8] clause 8.2.1. 

NOTE: Encapsulation of H.245 [7] messages within H.225.0 [5] is preferred to a separate H.245 [7] channel 
because of its greater efficiency. 

6.2.5 Support of in-band information coming from the SCN 

If the Progress indicator information element containing the progress description numbers 1 or 8 is received, then the IP 
network shall ensure that the media channel is open. The Gateway shall forward all in-band information from the SCN 
to the IP Network. 

If in-band information is present it shall be forwarded to the user. 

NOTE: If the value of the progress indicator information element is different from 1 and 8 or no Progress 
indicator information element is present, an indication may be generated locally. 

If the Gateway, connected to SCN, receives a PROGRESS message (before an ALERTING message is received) or a 
CALL PROCEEDING message (after a CALL PROCEEDING message has already been sent) with the Progress 
indicator information element included from SCN, the Gateway shall send a PROGRESS message to the Gatekeeper. 
The message shall contain the received Progress information element, or, if the content of the received Progress 
information element is not valid within H.225.0 [5], this shall be mapped to a suitable value. 

If the message received from SCN is the CALL PROCEEDING message and the CALL PROCEEDING message has 
not already been sent, the Gateway shall send a CALL PROCEEDING message. The message shall contain the Progress 
indicator information element, or, if the content of the received Progress information element is not valid within 
H.225.0 [5], this shall be mapped to a suitable value. 

When the Gatekeeper receives a CALL PROCEEDING message with a Progress indicator element included the 
Gatekeeper shall (before transferring the CALL PROCEEDING message) stop any running call supervision timer and 
start timer T301. 

When the Gatekeeper receives a PROGRESS message (before an ALERTING message is received) with the Progress 
indicator information element included (but no cause element) the Gatekeeper shall (before transferring the 
PROGRESS message) stop any running call supervision timer and start timer T301. 

When the H.323 [8] Terminal receives a CALL PROCEEDING message with a Progress indicator element included the 
H.323 [8] Terminal shall stop any running call supervision timer and start timer T301. 

When an H.323 [8] Terminal receives a PROGRESS message (before an ALERTING message is received) with a 
Progress indicator information element included (but no Cause information element is included, see clause 5.4.2.5.2) 
the H.323 [8] Terminal shall stop any running call supervision timer and start timer T301. 

6.3 Active Phase 

The active phase of the call shall commence when the called party in the SCN answers and the Gateway receives the 
CONNECT message as a result. The Gateway shall pass that CONNECT message on towards the originating H.323 [8] 
Terminal. 

Information received from the H.323 [8] Terminal in the userlnputlndication message specified in 

ITU-T Recommendation H.245 [7] shall be extracted from the userlnputlndication message and injected into the 

media stream by using DTMF tones. This shall be done by the Gateway connected to the SCN. 

DTMF tones received from the SCN in the media stream shall be detected by the Gateway and encoded in 
userlnputlndication messages specified in ITU-T Recommendation H.245 [7]. 

NOTE: The userlnputlndication could be tunnelled via the FACILITY message if necessary. 
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6.4 Call release 

6.4.1 Basic Call Release 

Call release may be initiated by the H.323 [8] Terminal, the Gateway (e.g. as a result of the terminal in the SCN 
initiating release), or the Gatekeeper. The reason for initiating call release may e.g. be normal disconnection of a call or 
a call failure. 

Message collisions shall be handled by H.323 [8] Terminals, Gatekeepers and Gateways. 

NOTE: Message collision occurs when the H.323 [8] Terminal and the Gateway initiate clearing at the same time. 

6.4.2 In-band Information 

If the Gateway, connected to an SCN, receives a Progress indicator information element in a DISCONNECT message 
from the SCN, the Gateway shall send a PROGRESS message to the Gatekeeper. The message shall include both the 
Progress indicator information element and the received cause. If the content of the received Progress information 
element is not valid within H.225.0 [5], this shall be mapped to a suitable value. 

When the Gatekeeper receives a PROGRESS message with both the Progress indicator information element and the 
Cause information element included the Gatekeeper shall (before transferring the PROGRESS message) stop any 
running call supervision timer and start timer T.301. 

When the H.323 [8] Terminal or the Gateway receives a PROGRESS message with both the Progress indicator 
information element and the Cause information element included, it shall stop any running call supervision and start 
timer T.301. 

7 Calls from a terminal in an SCN to an H.323 Terminal 

7.1 Overview 

A call from a terminal in an SCN to an H.323 [8] Terminal can be separated in three phases: call setup, active phase and 
call release. Figure 2 shows the information flows related to call establishment. 
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NOTE: This figure reflects ITU-T Recommendation Q.931 [13] cases only. 
Figure 2: Example of Scenario 2 call setup using overlap sending and Gatekeeper routed call model 

7.2 Call setup 
7.2.1 Basic call setup 

Calls shall be setup using the procedures defined in ITU-T Recommendation H.323 [8] with the following 
changes/clarifications: 

- Within the context of the present document, call setup shall use only one user channel from the SCN. Calls 
requiring a number of user channels shall not be supported. 

The Gatekeeper and its Gateway shall support both the en-bloc and the overlap sending procedure. 

In the case where two endpoints are registered to different gatekeepers and the gatekeeper-routed call model is 
used, TIPHON-compliant systems should use "called endpoint signalling." 

NOTE 1 : "Called endpoint signalling" is of benefit with regard to the use of NAT and firewall devices. However, 
its use is an administrative decision. 

Within IP networks, if an element or a message not allowed to be used within the context of the present document is 
received, the receiver shall pass on, but otherwise ignore, the message or the element i.e. the receiver shall act as if the 
message or the element was not received. 

Within IP networks, if a element is received with a value, not allowed within the context of the present document, the 
receiver shall, if the element is optional, pass on, but otherwise ignore, the element (act as if the element is not received) 
or if the element is mandatory act as if the default value was received. 
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At a Gateway, the requirements of the SCN protocol shall modify the error handling procedures described above. A 
Gateway shall not pass on to the SCN any messages or information elements, or the contents of information elements, 
that would cause a protocol error in the SCN. Similarly, a Gateway shall not pass on to the IP network any messages or 
information elements, or the contents of those information elements, that would cause a protocol error in the IP 
network. Such messages, information elements, or the contents of information elements should be mapped to suitable 
alternative if such exist, be discarded if not mandatory to support, or be rejected by the Gateway. 

NOTE 2: The security policy of an operator's network or the security policy implemented in a network element may 
override the error handling as described above. 

In accordance with the use of the fast Connect procedure, the Gatekeeper shall set the mediaWaitForConnect 
parameter to TRUE before sending the SETUP message to the H.323 [8] Terminal. 

The Gatekeeper should remove the fastStart parameter from any message, received from the H.323 [8] Terminal, prior 
to the CONNECT message. 

NOTE 3: As a subscription option, the Gatekeeper may allow activation of the media channel in one or both 
directions prior to the CONNECT message for certain trusted users or equipment. 

7.2.2 En-bloc procedure 

Once the H.323 [8] Terminal is located by the Gatekeeper en-bloc procedures shall be used. If not already there, the 
Gatekeeper shall include the Sending complete information element towards the H.323 [8] Terminal. 

NOTE: In the optional DRC case, the Gateway shall take over the task of the Gatekeeper. 

En-bloc procedure shall also be used whenever the Called Party Number in the Setup message can be regarded as 
complete by the Gatekeeper. 

7.2.3 Overlap sending 

The Gateway shall support overlap sending on the SCN interface. If the addressed H.323 [8] endpoint supports it, the 
Gatekeeper may use overlap sending towards the endpoint. 

NOTE: If the SCN uses overlap sending, the Gateway or its Gatekeeper need to retain the digits received until the 
H.323 [8] Terminal can be found. 

7.2.4 Establishment of media channels 

7.2.4.1 Fast Connect procedure 

TIPHON-compliant systems shall use the Fast Connect procedure of ITU-T Recommendation H.323 [8] clause 8.1.7. 

NOTE 1 : This includes the capability to negotiate media channels using ITU-T Recommendation H.245 [7] or to 
fall back to ITU-T Recommendation H.245 [7] signalling at any time of the call. 

NOTE 2: This enables in-band information to be passed prior to call establishment. 

7.2.4.2 Encapsulation of H.245 messages within H. 225.0 messages 

TIPHON-compliant systems shall support encapsulation of ITU-T Recommendation H.245 [7] messages within 
ITU-T Recommendation H.225.0 [5] messages according to ITU-T Recommendation H.323 [8] clause 8.2.1. 

NOTE: Encapsulation of H.245 [7] messages within H.225.0 [5] is preferred to a separate H.245 [7] channel 
because of its greater efficiency. 
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7.2.5 Ring control tone 



When the called H.323 [8] Terminal responds with an ALERTING message the called H.323 [8] Terminal's Gatekeeper 
may start the ringing tone towards the calling party. If the Gatekeeper starts the ringing tone, then the Gatekeeper shall 
include the Progress Indicator information element with the PI set to No. 8 "In-band information or an applicable 
pattern is available". 

If a Gateway receives an ALERTING message which does not include a Progress indicator information element, with 
the PI set to No. 8 "In-band information or an applicable pattern is available", the Gateway shall start the ringing tone. 

If an ALERTING message is received on a call from an SCN, the Gateway shall include the Progress indicator 
information element with the PI set to No. 8 "In-band information or an applicable pattern is available" if the 
information is not already indicated. 

7.3 Active Phase 

The active phase of the call shall commence when the H.323 [8] Terminal answers the call. 

Information received from the H.323 [8] Terminal in the userlnputlndication message specified in 

ITU-T Recommendation H.245 [7] shall be extracted from the userlnputlndication message and injected into the 

media stream by using DTMF tones. This shall be done by the Gateway connected to the SCN. 

DTMF tones received from the SCN in the media stream shall be detected by the Gateway and encoded in 
userlnputlndication messages specified in ITU-T Recommendation H.245 [7]. 

NOTE: The userlnputlndication could be tunnelled via the FACILITY message if necessary. 

7.4 Call release 

7.4.1 Basic Call Release 

Call release may be initiated by the H.323 [8] Terminal, the Gateway (e.g. as a result of the terminal in the SCN 
initiating release), or the Gatekeeper. The reason for initiating call release may e.g. be normal disconnection of a call or 
a call failure. 

Message collisions shall be handled by H.323 [8] Terminals, Gatekeepers and Gateways. 

NOTE: Message collision occurs when the endpoint and the Gateway initiate clearing at the same time. 

7.4.2 In-band Information 

If the Gateway, connected to an SCN, receives a progress indicator information element in a DISCONNECT message 
from the SCN the Gateway shall send a PROGRESS message to the Gatekeeper. The message shall include both the 
Progress indicator information element and the received cause. If the content of the received Progress information 
element is not valid within H.225.0 [5], this shall be mapped to a suitable value. 

When the Gatekeeper receives a PROGRESS message with both the Progress indicator information element and the 
Cause information element included the Gatekeeper shall (before transferring the PROGRESS message) stop any 
running call supervision timer and start timer T.301. 

When the H.323 [8] Terminal or the Gateway receives a PROGRESS message with both the Progress indicator 
information element and the Cause information element included, it shall stop any running call supervision and start 
timer T.301. 
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8 



Calls between SCN Terminals routed through an IP 
network 



8.1 



Overview 



A call between two Terminals in the SCN, routed through an IP network, can be separated in three phases: call setup, 
active phase and call release. Figure 3 shows the information flows related to call establishment. 
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NOTE 1 : As soon as the Gatekeeper has received sufficient digits to route the call, it shall send Setup to the egress 

Gateway. 
NOTE 2: Information messages may be sent as a result of a user providing more information. 
NOTE 3: If the SCN has received sufficient digits to complete number analysis, Call Proceeding shall be sent 

instead of Setup Ack in response to Setup and the Information message(s) will be discarded. 

Figure 3: Example of scenario 3 call setup using overlap sending 

8.2 Call Setup 
8.2.1 Basic call setup 

Calls shall be setup using the procedures defined in ITU-T Recommendation H.323 [8] with the following 
changes/clarifications: 

- Within the context of the specification, call setup shall use only one user channel from the SCN. Calls requiring 
a number of user channels shall not be supported; 

The Gatekeeper and the Gateways shall support both the en-bloc and the overlap sending procedure; 

In the case where two endpoints are registered to different gatekeepers and the gatekeeper-routed call model is 
used, TIPHON-compliant systems should use "called endpoint signalling". 

NOTE 1 : "Called endpoint signalling" is of benefit with regard to the use of NAT and firewall devices. However, 
its use is an administrative decision. 
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Within IP networks, if an element or a message not allowed to be used within the context of the specification is 
received, the receiver shall pass on, but otherwise ignore, the message or the element i.e. the receiver shall act as if the 
message or the element was not received. 

Within IP networks, if a element is received with a value, not allowed within the context of the present document, the 
receiver shall, if the element is optional, pass on, but otherwise ignore, the element (act as if the element is not received) 
or if the element is mandatory act as if the default value was received. 

At a Gateway, the requirements of the SCN protocol shall modify the error handling procedures described above. A 
Gateway shall not pass on to the SCN any messages or information elements, or the contents of information elements, 
that would cause a protocol error in the SCN. Similarly, a Gateway shall not pass on to the IP network any messages or 
information elements, or the contents of those information elements, that would cause a protocol error in the IP 
network. Such messages, information elements, or the contents of information elements should be mapped to suitable 
alternative if such exist, be discarded if not mandatory to support, or be rejected by the Gateway. 

NOTE 2: The security policy of an operator's network or the security policy implemented in a network element may 
override the error handling as described above. 

8.2.2 En-bloc procedure 

The En-bloc procedure may be explicitly indicated in the signalling from the originating SCN. If the originating SCN 
uses the en-bloc procedure, and there is sufficient information to enable the call to be routed to the egress Gateway, call 
establishment shall be initiated to the terminating SCN. 

8.2.3 Overlap sending 

The Gateways shall support overlap sending on their SCN interface. 

NOTE: If the originating SCN uses overlap sending, the ingress Gateway or its Gatekeeper need to retain the 
digits received until the egress Gateway can be found. 

On receipt of a SETUP message with a Called party number which the Gatekeeper cannot determine to be complete, the 
Gatekeeper starts timer T302 (the value of timer T302 is specified in ITU-T Recommendation Q.931 [13]) and sends a 
SETUP ACKNOWLEDGE message back. 

The Gatekeeper shall restart timer T302 on the receipt of every INFORMATION message not containing a sending 
complete indication and containing the called party information element with at least one valid character. 

8.2.4 Establishment of media channels 

8.2.4.1 Fast Connect procedure 

TIPHON-compliant systems shall use the Fast Connect procedure of ITU-T Recommendation H.323 [8] clause 8.1.7. 

NOTE 1 : This includes the capability to negotiate media channels using ITU-T Recommendation H.245 [7] or to 
fall back to ITU-T Recommendation H.245 [7] signalling at any time of the call. 

NOTE 2: This enables in-band information to be passed prior to call establishment. 

8.2.4.2 Encapsulation of H.245 messages within H. 225.0 messages 

TIPHON-compliant systems shall support encapsulation of ITU-T Recommendation H.245 [7] messages within 
ITU-T Recommendation H.225.0 [5] messages according to ITU-T Recommendation H.323 [8] clause 8.2.1. 

NOTE: Encapsulation of H.245 [7] messages within H.225.0 [5] is preferred to a separate H.245 [7] channel 
because of its greater efficiency. 

8.2.5 Support of in-band information coming from the SCN 

If the Progress indicator information element containing the progress description numbers 1 or 8 is received, then the IP 
network shall ensure that the media channel is open. 
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If the egress Gateway, receives a PROGRESS message (before an ALERTING message is received) or a 
CALL PROCEEDING message (after a CALL PROCEEDING message has already been sent) with the Progress 
indicator information element included from SCN, the Gateway shall send a PROGRESS message to the Gatekeeper. 
The message shall contain the received Progress information element, or, if the content of the received Progress 
information element is not valid within H.225.0 [5], this shall be mapped to a suitable value. 

If the message received from SCN is the CALL PROCEEDING message and the CALL PROCEEDING message has 
not already been sent, the egress Gateway shall send a CALL PROCEEDING message. The message shall contain the 
Progress indicator information element, or, if the content of the received Progress information element is not valid 
within H.225.0 [5], this shall be mapped to a suitable value. 

When the Gatekeeper receives a CALL PROCEEDING message with a Progress indicator element included the 
Gatekeeper shall (before transferring the CALL PROCEEDING message) stop any running call supervision timer and 
start timer T301. 

When the Gatekeeper receives a PROGRESS message (before an ALERTING message is received) with the Progress 
indicator information element included (but no cause element, see clause 5.4.2.5.2) the Gatekeeper shall (before 
transferring the PROGRESS message) stop any running call supervision timer and start timer T301. 

When an ingress Gateway receives a CALL PROCEEDING message with a Progress indicator element included, the 
ingress Gateway shall (before transferring the PROGRESS message) stop any running call supervision timer and start 
timer T301. 

When an ingress Gateway receives a PROGRESS message (before an ALERTING message is received) with a Progress 
indicator information element included (but no Cause information element is included), the ingress Gateway shall 
(before transferring the PROGRESS message) stop any running call supervision timer and start timer T301. 

8.3 Active Phase 

The active phase of the call shall commence when the called party in the terminating SCN answers and the egress 
Gateway receives the Connect message as a result. 

DTMF tones received from the originating SCN in the media stream shall be passed on to the terminating SCN. 

8.4 Call Release 

8.4.1 Basic Call Release 

Call release may be initiated by any Gateway (e.g. as a result of the terminal in the SCN initiating release), or the 
Gatekeeper. The reason for initiating call release may e.g. be normal disconnection of a call or a call failure. 

Message collisions shall be handled by Gatekeepers and Gateways. 

NOTE: Message collision occurs when both Gateways initiate clearing at the same time. 

8.4.2 In-band Information 

If any Gateway, connected to an SCN, receives a Progress indicator information element in a DISCONNECT message 
from the SCN the Gateway shall send a PROGRESS message to the Gatekeeper. The message shall include both the 
Progress indicator information element and the received cause. If the content of the received Progress information 
element is not valid within H.225.0 [5], this shall be mapped to a suitable value. 

When the Gatekeeper receives a PROGRESS message with both the Progress indicator information element and the 
Cause information element included the Gatekeeper shall (before transferring the PROGRESS message to the other 
gateway) stop any running call supervision timer and start timer T.301. 

When a Gateway receives a PROGRESS message with both the Progress indicator information element and the Cause 
information element included, it shall stop any running call supervision and start timer T.301. 
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Calls between H.323 Terminals routed through an 
SCN 



9.1 



Introduction 



There are a number of different physical configurations that may be considered to represent the logical relationship of 
Scenario 4. For the purposes of the present document, Scenario 4 shall be considered to comprise a call originated as 
per Scenario 1 followed by a call termination as per Scenario 2. More complex interpretations of this scenario are 
possible but are deferred to other TIPHON deliverables for consideration. 

A call between two H.323 [8] Terminals, routed through an SCN, can be separated in three phases: call setup, active 
phase and call release. Figure 4 shows the information flows related to call establishment. 



H.323 Terminal 
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Gateway 
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H.323 Terminal 
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NOTE 1 : As soon as the Gatekeeper has received sufficient digits to route the call, it shall send Setup to the 

Gateway. 
NOTE 2: Information messages may be sent as a result of a user providing more information. 
NOTE 3: The SCN may actually consist of several networks using diverse technologies. 
NOTE 4: The Gateway or its Gatekeeper need to retain the digits received until the H.323 [8] Terminal can be 

found. 

Figure 4: Example of Scenario 4 call setup diagram using overlap sending 



9.2 Call Setup 



For the originating network, clause 6.2 shall apply. For the terminating network, clause 7.2 shall apply. 



9.3 



Active Phase 



For the originating network, clause 6.3 shall apply. For the terminating network, clause 7.3 shall apply. 
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9.4 Call release 

For the originating network, clause 6.4 shall apply. For the terminating network, clause 7.4 shall apply. 



10 Other Issues 

10.1 Interworking with Dual Tone Multi- Frequency (DTMF) 
signalling 

Before the media channels are established in both directions, all dialled information shall be sent in the Called party 
number information element or in the Keypad facility information element using H.225.0 [5] messages. The Gatekeeper 
receiving Keypad facility information elements shall use Called party number information elements if the digits are to 
be forwarded. 

In scenario 3, if the transmission facilities in the IP network can convey DTMF tones in band, then conversion to 
out-of-band userlnputlndication messages shall not be used. Otherwise, after the media channels have been 
established in both directions, transfer of the DTMF tones within the IP network shall be by means of the 
ITU-T Recommendation H.245 [7] message userlnputlndication. The alphanumeric format of the 
userlnputlndication message shall be used. 

Terminals unable to originate userlnputlndication may send dialled information using the Keypad facility information 
element of the INFORMATION message. The Gatekeeper receiving Keypad facility information elements shall use 
userlnputlndication messages if the digits are to be forwarded. 

The Gateway shall use the information in userlnputlndication, inject it into the media stream as DTMF tones, and 
pass it to the SCN. 

NOTE: The userlnputlndication could be tunnelled via the FACILITY message if necessary. 

10.2 Carrier selection 

Carrier selection shall be performed by transmitting the necessary information to the Gatekeeper and Gateway within 
the called party number field. This procedure shall not preclude overlap sending. 

1 0.3 Detection of failure during the setup of the call 

Upon detection of failure of the call in the IP network, accounting and charging functions shall be informed. 

NOTE 1 : In order to detect call failures in the IP network, which affect accounting and charging functions, 

Gatekeepers should specify an irrFrequency value inside the AdmissionConfirm (RAS message) (ACF). 

If the Gatekeeper detects a failure, the Gatekeeper shall initiate clearing of the call as described in clauses 6.4, 7.4, 8.4 
and 9.4, "Call release". 

If the Gateway detects a failure, the Gateway shall initiate clearing towards the SCN, and clear the call in the IP 
network as described in clauses 6.4, 7.4, 8.4 and 9.4, "Call release". 

If the H.323 [8] Terminal detects a failure, the H.323 [8] Terminal shall initiate clearing of the call as described in 
clauses 6.4, 7.4, 8.4 and 9.4, "Call release". 
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10.4 Calling Line Identification (CLI) 



CLI information may be provided by calling users and may be received by called users. When a H.323 [8] Terminal 
wishes to provide a calling number it shall be provided using the signalling elements described in 
ITU-T Recommendation H.225.0 [5]. 

H.323 [8] Terminals may provide a number using the optional Calling Party Number information element in the Setup 

message. 

NOTE: The procedures and protocols for handling these information elements may be defined in regional and 
national regulations and/or codes of practice. Wherever such requirements exist they may supersede the 
requirements expressed here. 

According to ITU-T Recommendation H.225.0 [5] the number cannot have qualifications defined in accordance with 
octet 3 a information (Presentation Indicator and Screening Indicator) as in tables 4 to 1 1 of 
ITU-T Recommendation Q.931 [13]. Accordingly in the absence of octet 3a information the calling party number 
information element shall be treated as if octet 3a contained the following values: 

1) "presentation allowed"; and 

2) "user-provided not screened". 

As a consequence of the above the Gateway shall not include the Calling party number IE in the SETUP message 
towards the IP network if the Calling party information, received from the SCN network, indicates a restriction. 



1 0.5 Use of alternate Gatekeepers 



Gatekeepers shall convey information about as many alternate Gatekeepers as possible within security considerations, 
using the alternate Gatekeeper fields: alternateGK and altGKInfo as defined in ITU-T Recommendation H.225.0 [5]. 

Endpoints shall: 

support alternate Gatekeeper structures: upon receipt of an alternate Gatekeeper list, endpoint shall update their 
internal registry; 

- use the most recent alternate Gatekeeper list received in RAS responses; 

the alternate Gatekeeper list shall not contain more than 16 alternate Gatekeepers. 

1 0.6 Support of SET devices (H.323 Annex F) 

TIPHON compliant systems may support Simple Endpoint Type devices as defined in ITU-T Recommendation H.323 
[8] Annex F. In this case the following shall be taken into account: 

SET devices support FastConnect only. They need not open a separate H.245 [7] connection and need not 
support encapsulation of H.245 [7] in H.225.0 [5] messages; 

SET devices shall support transmission of DTMF as Keypad Information Elements in the 
ITU-T Recommendation H.225.0 [5] call signaling connection (i.e. using Information messages). 

If a TIPHON compliant Gatekeeper supports SET devices it shall: 

Provide mapping of DTMF coding in H.225.0 [5] Keypad Information Elements in Information messages to 
H.245 [7] Userlnputlndication Messages; 

Provide preGrantedARQ for SET devices; 

Be aware that SET devices only support Gatekeeper routed calls; 

- Not require Information Request Response (IRR) Messages to be sent by SET devices. 
SET devices have to comply with all passages of the present document, if not explicitly stated. 
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1 0.7 Support of iNOW! Terminals 

IMTC iNOW! Terminals [8] may be supported by TIPHON compliant systems if they comply with all passages of the 
present document. As iNOW Terminals are a special form of SET devices, the Gatekeeper has to be aware of this and 
clause 5.9 "Support of SET devices (H.323 [8] Annex F shall apply). 

Restriction: as iNOW compliant Terminals need not support call redirection during the life of a call, the call shall be 
disconnected if this feature is requested. 

NOTE: The security options of iNOW Terminals have to be analysed in detail, during the phase of Threat 

analysis in the TIPHON WG1 activities. It might be necessary to add additional requirements to iNOW 
Terminals to be TIPHON compliant. 
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Annex A (normative): 

Required support of H. 225.0 call control protocol 

ITU-T Recommendation H.323 [8] uses a call control protocol derived from ITU-T Recommendation Q.931 [13] which 
is specified in the ITU-T Recommendation H.225.0 [5]. 

This annex defines a profile which is intended to clarify the use of ITU-T Recommendation H.225.0 [5] in 
TIPHON-compliant systems. Whenever the contents of this annex are in conflict with ITU-T Recommendation 
H.225.0 [5] this annex shall take precedence. 

The current version of the ITU-T RECOMMENDATION Q.931 [13] part of ITU-T Recommendation H.225.0 [5] 
includes a number of optional messages and information elements. The ETS 300 403-1 [2] standard (ETSI DSS1) 
forbids some of the information elements which are optional in ITU-T Recommendation H.225.0 [5], listed below. 
Gateways that interconnect with ETSI DSS1 networks shall not send these information elements. 

Table A.l identifies changes to entries in table 4 of ITU-T Recommendation H.225.0 [5]. 

The changes in the table shall apply to TIPHON Phase 3 systems. 

Table A.1 : Modification to ITU-T Recommendation H.225.0 [5] 
Usage of ITU-T RECOMMENDATION Q.931 [13] and Q.932 [14] Messages 



Call Establishment Messages 


Transmit (M, CM) 


Receive and act on (M, CM) 


Call Proceeding 


M 


M 


Progress 


M 


M 


Setup Acknowledge 


M 


CM (see note 1 ) 








Miscellaneous Messages 






Information 


CM 


M 


NOTE 1 : Only mandatory if the H.323 [8] Terminal indicates canOverlapSend in the Setup message. 
NOTE 2: M = mandatory, CM = conditionally mandatory. 



A.1 Alerting 



Table A.2 identifies changes to entries in the table 5 of ITU-T Recommendation H.225.0 [5]. 

Table A.2: Modifications to ITU-T Recommendation H.225.0 [5] 
Usage of the Alerting message 



Information element 


H.225.0 [5] status 


Length in H.225.0 [5] 


Signal 


F 


NA 


NOTE: F = forbidden. 



A.2 Information 

Table A.3 identifies changes to entries in the table 9 of ITU-T Recommendation H.225.0 [5]. 

Table A.3: Modifications to ITU-T Recommendation H.225.0 [5] 
Usage of the Information message 



Information element 


H.225.0 [5] status 


Length in H.225.0 [5] 


Signal 


F 


NA 
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A.3 Release Complete 



Table A.4 identifies changes to entries in the table 10 of ITU-T Recommendation H.225.0 [5]. 

Table A.4: Modifications to ITU-T Recommendation H.225.0 [5] 
Usage of the Release Complete message 



Information element 


H.225.0 [5] status 


Length in H.225.0 [5] 


Signal 


F 


NA 



A.4 Setup 



Table A.5 identifies changes to entries in the table 11 of ITU-T Recommendation H.225.0 [5], 

Table A.5: Modifications to ITU-T Recommendation H.225.0 [5] 
Usage of the Setup message 



Information element 


H.225.0 [5] status 


Length in H.225.0 [5] 


Signal 


F 


NA 



A.5 Setup Acknowledge 



The contents and semantics of a SETUP ACKNOWLEDGE message received from the network are defined in 

tables 3 to 16 of ITU-T Recommendation Q.931 [13] with the single modification that the Signal information element is 

not allowed. 
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